Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-023.txt

Text File | 1992-11-18 | 70.0 KB | 1,949 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 20 Mar 92       Volume 1 : Issue 23

Today's Topics:

    Mac Pascal vs. C


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (robert dixon)
Subject: Mac Pascal vs. C
Date: 31 Jan 92 18:09:02 GMT
Organization: Naval Postgraduate School, Monterey CA

In article <kdW=[e-mail]> [e-mail] (Robert H Earhart) writes:
>
>  So write in Pascal... it's easier than C...
>
>  -Rob

  Language wars are always so messy . . .

  Like I said in my original posting, my programming background is in
the PC world, and I've programmed in both Turbo Pascal and Turbo C++.
I don't know much about Macintosh Pascal compilers vs. Macintosh C
compilers, but I find C a little easier for a couple of reasons.
First, it's designed as a more low-level language, so it's a little
easier to access operating system features that the language library
designer didn't think was "important". On the PC I've had to write
assembler subroutines for Turbo Pascal that did simple things like
deleting files and subdirectories.  It's much easier to do things like
that in C, because C was designed to support separately compiled code.

  C's notation for some things is a little more compact, although that
can certainly lead to cryptic code.

  I like Pascal quite a bit. I just personally find C easier.

  At the risk of starting a fight, do people find Macintosh Pascal to
be just as easy and efficient as Macintosh C?

Bob Dixon



- -------------------------

From: [e-mail] (Robert H Earhart)
Subject:  Mac Pascal vs. C
Date: 1 Feb 92 17:21:31 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA


  No need for a fight... on the PC, C is DEFINITLY the way to go,
along with the Turbo compiler... on Unix, C's also wonderful. On the
Mac though...

  1. Inside Macintosh was written in Pascal.
  2. Pascal forces you to declare EVERYTHING, encouraging good
programming vs. hacks (though you can hack in either...)
  3. Think's Pascal compiler is so great, it's hard to think of an
equal. It's the reason I program on Macs, rather than Dec stations.
The C compilers I've seen aren't nearly as integrated, and are
generally poorer. The only thing C has in its favor is it's 'for'
loops, and Pascal makes up for that with sets...

  But in the end, it's all personal preference... use what you like!
Libraries can be used by almost anything... :)

  -Rob



- -------------------------

From: [e-mail] (Louis Wu)
Subject:  Mac Pascal vs. C
Date: 1 Feb 92 18:41:52 GMT
Organization: Whatsamatta U


I couldn't let this pass.

>   No need for a fight... on the PC, C is DEFINITLY the way to go,
> along with the Turbo compiler... on Unix, C's also wonderful. On the
> Mac though...
>
>   1. Inside Macintosh was written in Pascal.
So what. Any pascal var parameter is a pointer in C. It's *very*
straightforward to call pascal routine routines from C.

>   2. Pascal forces you to declare EVERYTHING, encouraging good
> programming vs. hacks (though you can hack in either...)
Key word being 'force'. C allows you to declare prototypes if you want.
Think C will force you to cast all pointers if you want. Or you don't have
to, if you don't want. I don't like to be forced to do anything "for my own
good".

>   3. Think's Pascal compiler is so great, it's hard to think of an
> equal. It's the reason I program on Macs, rather than Dec stations.
> The C compilers I've seen aren't nearly as integrated, and are
> generally poorer. The only thing C has in its favor is it's 'for'
> loops, and Pascal makes up for that with sets...
>
Arrgh. You say the Think Pascal compiler is so good, ever looked at Think's
C compiler? Strangely enough, they are similar...

Pascal is for beginners, C is for real programmers, and assembly is for
masochists. Surely nothing could be more clear.

:-)
--
=============================================================================
Pete Keleher   "Relax! Don't worry! Have a homebrew!"        [e-mail]
=============================================================================



- -------------------------

From: [e-mail] (robert dixon)
Subject:  Mac Pascal vs. C
Date: 1 Feb 92 20:47:15 GMT
Organization: Naval Postgraduate School, Monterey CA

In article <[e-mail]> [e-mail] (Robert H Earhart) writes:
>
>  No need for a fight... on the PC, C is DEFINITLY the way to go,
>along with the Turbo compiler... on Unix, C's also wonderful. On the
>Mac though...
>
>  3. Think's Pascal compiler is so great, it's hard to think of an
>equal. It's the reason I program on Macs, rather than Dec stations.

  Does Think Pascal support anything resembling object orientation?
How about separately compiled code, i.e. linking in other code you
wrote and compiled before?

- -------------------------------------------------------------------
Bob Dixon
[e-mail]              "My opinions may not necessarily
Low-Life Grad Student,              be my own . . ."
Naval Postgraduate School,
Monterey, CA
- ---------------------------------------------------------------------



- -------------------------

From: [e-mail] (robert dixon)
Subject:  Mac Pascal vs. C
Date: 1 Feb 92 20:53:12 GMT
Organization: Naval Postgraduate School, Monterey CA

In article <[e-mail]> [e-mail] (Louis Wu) writes:
>
>I couldn't let this pass.
>>>
>Arrgh. You say the Think Pascal compiler is so good, ever looked at Think's
>C compiler? Strangely enough, they are similar...
>
>Pascal is for beginners, C is for real programmers, and assembly is for
>masochists. Surely nothing could be more clear.
>
>:-)
>--

  See, I said this question would start a fight.

  How "object-oriented" is Think C?  Does it support classes?
Inheritance?  Function name overloading?  Public and private variables
and functions?  How about reference variables?


- -------------------------------------------------------------------
Bob Dixon                          "My opinions may not necessarily
Low-Life Grad Student,              be my own . . ."
Naval Postgraduate School,
Monterey, CA
- ---------------------------------------------------------------------



- -------------------------

From: [e-mail] (Robert H Earhart)
Subject:  Mac Pascal vs. C
Date: 2 Feb 92 07:27:02 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA

[e-mail] (Louis Wu) writes:
> Arrgh. You say the Think Pascal compiler is so good, ever looked at Think's
> C compiler? Strangely enough, they are similar...

  As a matter of fact... I'm fairly fluent in both. The Pascal one is
nicer... :)

> Pascal is for beginners, C is for real programmers, and assembly is for
> masochists. Surely nothing could be more clear.

  Hey! I resent that! Pascal is NOT a beginner language in and of
itself... it's all in the skill of the programmer...

  Pascal supports OOP very well... It's actually quite useful (Again,
I speak of Think's Pascal: the Pascal standard is a hose...)

  Seperately compiled code... it'll make libraries, and accept
libraries from Think C, MPW, and a few others... you can also use
units, if you prefer... and because of Pascal's "Declare it before you
use it" rule, you don't wind up having the compiler just sort of
trusting the linker to get everything straight in the end...  and
because of the scope rules, you know EXACTLY what things are being
shared by what units at all times...

  So not only CAN you re-use old code, but it makes it a lot EASIER to
reuse old code, as well as making it easier to split your program up
into units and still have it compile properly...

  And this ISN'T a fight; I think we're all capable of discussing the
merits of various languages w/o taking things personally... for
example, I wouldn't dream of programming a UNIX machine with anything
BUT C...

  That's what the smiley's are for. :)

> :-)

  :)

  -Rob



- -------------------------

From: [e-mail] (Jerry Frain)
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 08:16:28 GMT
Organization: Kansas State University

[e-mail] (Robert H Earhart) writes:

>On the Mac

>  1. Inside Macintosh was written in Pascal.

This does make programming in C somewhat of a pain for programmers
just becoming familiar with the Mac.  It is not hard to transfer from
Pascal to C and vice-versa once you get used to it, but I it can be a
little confusing at first (of course if Apple would've been on the
ball the first time 'round, they would've used C instead of Pascal ;-) )

>  2. Pascal forces you to declare EVERYTHING

Big deal.  So does C -- just try to compile a program where you've not
declared a variable or function at all.  The linker'll catch ya.

Now, if you mean that Pascal doesn't allow forward referencing, while
C allows prototyping or declares a function to return int, well,
that's a product of the fact that both compilers want to do everything
in one pass, they just solve declarations problem differently.

C gives the programmer choice, while Pascal rigidly enforces Wirth's
choice.

>encouraging good programming vs. hacks (though you can hack in either...)

Good programming is where you find it.  Most of the Pascal code out
there is "prettier" (indention, etc) than most C code out there, but
I'd have to say that a lot of the ugly C code out there is written
by converted Pascal programmers who is can't figure out "where those
darn curly braces go".

>  3. Think's Pascal compiler is so great, it's hard to think of an
>equal. It's the reason I program on Macs, rather than Dec stations.

Just because a particular compiler is appealing is hardly a reason to
use a language.  I bet if I came up with a nifty COBOL compiler for
the Mac there wouldn't be too many Pascal or C converts.

If you like nice environments to program under try Emacs and C on a
Unix system.  Now, there's an unbeatable combination.

>The C compilers I've seen aren't nearly as integrated,

Funny, I always thought of "integrated" compilers as Evil.  After all,
I'd rather use my favorite editor, assembler, make facility, and
debugger, than have to rely on one package to provide the best of all
of those things (and they never do).

>The only thing C has in its favor is it's 'for' loops, and Pascal
>makes up for that with sets...

C is standardized.

C has a preprocessor.

C has a more standard OOP extension (C++, objective C stinks).

>  But in the end, it's all personal preference... use what you like!

I think that if you have a good, consistent coding style, and follow a
good convention for variable naming, C is much cleaner and more concise
to read than Pascal.

Just MHO, of course.

- ----------------------------------------------------------------------------
Jerry Frain, Systems Programmer         |  "Back off man, I'm a scientist."
Kansas State University                 |  [e-mail]
Department of Computer & Info Sciences  |  ...!rutgers!depot!frain



- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 15:40:41 GMT
Organization: CIS Dept., Syracuse University

In article <[e-mail]> [e-mail] (Jerry Frain) writes:

>C has a more standard OOP extension (C++, objective C stinks).

Close.  ALL versions of C stink.



Oh well.  I guess I probably just started a flame war...

--
greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail] (Eric W. Douglas)
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 05:38:07 GMT


[e-mail] (Robert H Earhart) writes:

>[e-mail] (Louis Wu) writes:
>> Arrgh. You say the Think Pascal compiler is so good, ever looked at Think's
>> C compiler? Strangely enough, they are similar...

>  As a matter of fact... I'm fairly fluent in both. The Pascal one is
>nicer... :)

>> Pascal is for beginners, C is for real programmers, and assembly is for
>> masochists. Surely nothing could be more clear.

>  Hey! I resent that! Pascal is NOT a beginner language in and of
>itself... it's all in the skill of the programmer...

[ rest deleted ]

Why is it, time and time again, I hear this discussion? Are there really
that many people out there with this much time on their hands, to sit around
and bicker about what semantics make any language better than another?

Look, on the Mac, Pascal, C, same difference to me... I've used both. Don't
ask me why, but I *like* Pascal better on the Mac, just like I *like* C
better under Unix. If we got into real issues, like how the machine code
compares from compiler to compiler, that would be a refreshing change. From
my observations, both THINK C and THINK Pascal produce very tight code. Others
argue about C's pointer indexing, which is something I've never had a problem
with in Pascal with proper type implementations. Then again, there's
portability, but hey, if you're developing software in C on the Mac, I
think it would be fair to say that you're not going to port anything to
another platform very easily.

And to however wrote the assembly remark: I like assembly for specific
tasks, and no, I don't like whips in, well, shall we say other facets
of my life :).

--eric

* | Eric W. Douglas             Technojock               [phone] | *
* | I'net: [e-mail]      [e-mail] | *
* | AppleLink: STUDIO.D      Compuserve: 76170,1472       AOL: EWDOUGLAS | *
____________________________________________________________________________



- -------------------------

From: [e-mail] (& Wise)
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 16:46:06 GMT
Organization: Organization?  I thought entropy would take care of that...

In article <[e-mail]> [e-mail] (robert dixon) writes:

     See, I said this question would start a fight.

Always does...

     How "object-oriented" is Think C?   Does it support classes?

THINK C has some OO features, they are basically the same ones that
THINK Pascal has (which are the Apple Object Pascal extensions), only
an effort has been made to make the syntax C++ compatible.

   Inheritance?

Yes. Single threaded.

   Function name overloading?

No.

   Public and private variables and functions?

No.

   How about reference variables?

Sorry.

It should be noted however, that there are a couple of C++ compilers
for the Mac.  Apple has an Cfront (2.1?) derived compiler for MPW, and
Zortech (now part of Symantec) is also available.  Neither are cheap
however...

        /s
--
Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory
/\/\/\/\/\/\/\/\/\/\/\/\/\/\ [e-mail] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\



- -------------------------

From: [e-mail] (& Wise)
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 16:51:19 GMT
Organization: Organization?  I thought entropy would take care of that...

In article <[e-mail]> [e-mail] (robert dixon) writes:

     Does Think Pascal support anything resembling object orientation?

Hey, I'll answer in this thread too!!

Yes.  THINK Pascal implements Apple's "Object Pascal."

   How about separately compiled code, i.e. linking in other code you
   wrote and compiled before?

Yes.  Object Pascal includes the UCSD unit construct, and you can
compile into libraries.  There are a few pragmas (embedded compiler
directives) you have to include in the unit specification to use a
library...

        /s
--
Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory
/\/\/\/\/\/\/\/\/\/\/\/\/\/\ [e-mail] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\



- -------------------------

From: [e-mail] (Douglas Hill)
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 19:42:34 GMT

>C has a more standard OOP extension (C++, objective C stinks).

 JG> Close.  ALL versions of C stink.
 JG> Oh well.  I guess I probably just started a flame war...

Well, you're right, you probably just did.  Why post it at all?  We've
all seen/read enough flames about C and Pascal in this and other groups.
Since this debate between C and Pascal is virtually unending can we move
on to more interesting programming topics?

Here's one:  Has anyone heard about MacApp's support for AppleEvents?
Specifically I heard recently that MacApp won't be supporting the
Object Support Library.  Why?  I wonder if something else better is in
the works?

Has anyone started using Frontier yet?  I heard that it shipped at MacWorld
in S.F.  I haven't heard much feedback from people who were writing
scripts with it.  (My guess is the lack of apps that are currently AE
driven.)

- Doug
  [e-mail]
  [e-mail]



 * Origin: Europa BBS [phone] HST/DS (1:109/438)



- -------------------------

From: [e-mail] (Owen M. Hartnett)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 01:59:11 GMT
Organization: Brown University Department of Computer Science

This item should be added to the FAQ list right after "Is or is not
the Mac a True Multi-tasking machine?"

-Owen
ZZ
Owen Hartnett                [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
        without knowledge, of things without parallel."
            -Ambrose Bierce - The Devil's Dictionary



- -------------------------

From: [e-mail] (Rui N Campos)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 01:43:52 GMT
Organization: University of Massachusetts Dartmouth

In <[e-mail]> [e-mail] (robert dixon) writes:

>In article <[e-mail]> [e-mail] (Robert H Earhart) writes:
>>
>>  No need for a fight... on the PC, C is DEFINITLY the way to go,
>>along with the Turbo compiler... on Unix, C's also wonderful. On the
>>Mac though...
>>
>>  3. Think's Pascal compiler is so great, it's hard to think of an
>>equal. It's the reason I program on Macs, rather than Dec stations.

>  Does Think Pascal support anything resembling object orientation?
>How about separately compiled code, i.e. linking in other code you
>wrote and compiled before?

Yes it does.  It even works with MacApp quite well.

One thin gwe shouldn't forget is that the Mac operating system was originaly
written in pascal.  so the versions of Pascal that are available for the Mac
are quite high powered.  As a matter of fact I remember seeing a Mac program
written in C for the first time (all previous programs were pascal) and
thinking that it looke an awful lot like pascal, but much messier.

It's just as easy to access the macs toolbox routines from pascal as it is in
C, so it really is a mater of preference.  And it is a matter of how well the
language reflects the problem domain.  I personally don't like C because it
forces me to deal with low level things that I at times don't really need to
know.  It is also really hard for the programmer to benefit from information
hiding since C doesn't help with this.

Rui



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 10:53:24 +1300
Organization: University of Waikato, Hamilton, New Zealand

Here's the answer to the debate:

    Use Modula-2!

Advantages over both Pascal and C:

* True separate compilation with scope control (the biggest plus, in my view)
* Better control constructs
* Somewhat improved types (opaque types, unsigned integer, environment queries)
  over Pascal, no comparison with C

Disadvantages:

* Case-sensitive (I hate this)
* Preserves some well-known Pascal pitfalls intact (e g the well-known VAR
  argument problem)

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.



- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Mac Pascal vs. C
Organization: CIS Dept., Syracuse University
Date: Mon, 3 Feb 92 22:49:57 EST

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>Here's the answer to the debate:
>
>    Use Modula-2!
>
>Disadvantages:
>
>* Case-sensitive (I hate this)

Don't most implementations have the ability to turn off case-sensitivity?

--
greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail]
Subject:  Mac Pascal vs. C
Date: 3 Feb 92 23:57:32 GMT
Organization: BC Systems Corporation

In article <[e-mail]>, [e-mail] (robert dixon) writes:
> In article <[e-mail]> [e-mail] (Louis Wu) writes:
>>
>>I couldn't let this pass.
>>>>
>>Arrgh. You say the Think Pascal compiler is so good, ever looked at Think's
>>C compiler? Strangely enough, they are similar...
>>
>>Pascal is for beginners, C is for real programmers, and assembly is for
>>masochists. Surely nothing could be more clear.
>>
>>:-)
>>--
>
>   See, I said this question would start a fight.

I must say that I own both THINK Pascal 4.0.1 and THINK C 5.0.2 and I'm very
impressed by both.  Pascal is mainly taught in schools (Grade 11 & 12) and in
first year university (up here in Canada anyway), therefore you can indeed come
to the assumption that "Pascal is for beginners".

I'm trying to learn C because it seems to be the way to go, along with OOP.  I
just purchased a book by Thom Hogan and Kurt Mathies called "Macintosh C
Programming By Example" which I'm finding very good. (It's published by
Microsft Press for those that are interested).  I also have the Macintosh C
primmer vols. 1 & 2.  I am desperately trying to learn C in my spare time.

I think both languages have their strong points and not so strong points, but I
do believe that the THINK environment for C & Pascal is the BEST ON THE
MARKET, especially for beginners in _both_ languages!!!!!


>
>   How "object-oriented" is Think C?  Does it support classes?
> Inheritance?  Function name overloading?  Public and private variables
> and functions?  How about reference variables?
>
In a word: yes!! (this applies to both Pascal and C [as far as I know] )

--
[e-mail]
British Columbia, Canada



- -------------------------

From: [e-mail] (Matt Mora)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 16:34:44 GMT
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Louis Wu) writes:

>Arrgh. You say the Think Pascal compiler is so good, ever looked at Think's
>C compiler? Strangely enough, they are similar...

No way! THINK Pascal environment is much better. It has the best debugger
around. I wish that Symantec would combine the two into one product since
the editors and the project handling seem to be equivelent.


--
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________



- -------------------------

From: [e-mail] (John Stracke)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 19:45:36 GMT
Organization: National Science Center Foundation

In article <[e-mail]> [e-mail] (Louis Wu) writes:

>Organization: Whatsamatta U

Again? :-)

>>   1. Inside Macintosh was written in Pascal.
>So what. Any pascal var parameter is a pointer in C. It's *very*
>straightforward to call pascal routine routines from C.

IM being written in Pascal is actually a problem.  All those places
where they have array[0..0] of X just freak Pascal out.

Still, it's nice to be able to look at exactly what you need.

>>   2. Pascal forces you to declare EVERYTHING, encouraging good
>> programming vs. hacks (though you can hack in either...)
>Key word being 'force'. C allows you to declare prototypes if you want.

Quite true.  I've noticed that I've become much more hackerly since
abandoning Pascal.

>Pascal is for beginners, C is for real programmers, and assembly is for
>masochists. Surely nothing could be more clear.

And where do things like Lisp fit in your scheme?

/===========================================================================\
|John (Francis) Stracke         |My opinions are my own.                    |
|Natl. Science Center Foundation|===========================================|
|Augusta, GA                    |This is the .sig that says...              |
|[e-mail]      |        Ni!                                |
\===========================================================================/
(Formerly [e-mail])
--
--



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 22:50:33 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>    Use Modula-2!
>Advantages over both Pascal and C:
>* Better control constructs

Debatable.  Matter of taste.

>Disadvantages:

* No variable-length argument lists.  Not even in built-ins (ie, no
  equivalent to Pascal's WRITE).

Or has Modula-2 been extended since the original Wirth book?
--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
Apparently-To: does more harm than good.



- -------------------------

From: [e-mail] (Quinn "The Eskimo!")
Subject:  Mac Pascal vs. C
Organization: The University of Western Australia
Date: Wed, 5 Feb 1992 00:59:59 GMT

In article <[e-mail]>, [e-mail] (Jonathan Greenfield) writes:
>
> In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> >
> >* Case-sensitive (I hate this)
>
> Don't most implementations have the ability to turn off case-sensitivity?

Tell that to the people at Metrowerks.  I mailed them specifically (they
replied which was nice) to ask "Is there any change of having a switch
to turn off case sensitivity /especially on keywords/?" and they mailed
back saying there was:
  a) no switch and no plan to put one in
  b) an MPW tool to uppercase keywords in Modula 2 source
A tool is not an ideal solution because it's too damned slow.

Quinn "The Eskimo!"   ([e-mail])   "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
-- One of the world's many case frustrated Modula 2 programmers!




- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Mac Pascal vs. C
Date: 5 Feb 92 02:21:34 GMT
Organization: CIS Dept., Syracuse University

In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>
>>Disadvantages:
>
>* No variable-length argument lists.  Not even in built-ins (ie, no
>  equivalent to Pascal's WRITE).
>
>Or has Modula-2 been extended since the original Wirth book?

You're missing the point though.  First of all, the IO procedures, etc, are
*not* built-ins in Modula-2.  They are contained in standard libraries that
are separate from the compiler (or should be, in any proper implementation).
Secondly, it is quite ugly to provide standard "procedures" that violate
the language's own rules for procedures.  Pascal's standard IO procedures
are lousy in this regard.

In other words, the language should either allow ALL procedures to have
variable-length parameter lists, or it should not allow ANY to have such
parameter lists.

--
greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail] (Thad Humphries)
Subject:  Mac Pascal vs. C
Date: 4 Feb 92 11:34:19 GMT


 &W>    Public and private variables and functions?
 &W>
 &W> No.

No by my reading of the THINK 5.0 OOP manual.  The method declaration looks like C++.

 * Origin: Quis custodiet ipsos custodes? (1:109/70.950)



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  Mac Pascal vs. C
Date: 5 Feb 92 15:52:43 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>>    Use Modula-2!
>>Advantages over both Pascal and C:
>>* Better control constructs
>
>Debatable.  Matter of taste.
>
>>Disadvantages:
>
>* No variable-length argument lists.  Not even in built-ins (ie, no
>  equivalent to Pascal's WRITE).

I actually once saw a version of MODULA-2 which had variable argument lists (to
make it interface to C libraries, it ran on a SUN).

>Or has Modula-2 been extended since the original Wirth book?

It has been revised in various ways. Mostly, it has been restricted, but there
are 3 or 4 editions of the Modula book and at least as many different compilers
from ETH only. And I hear there is currently a standard being prepared.

Matthias

- ---
Matthias Neeracher                                   [e-mail]
   "There once was an Age of Reason, but we've progressed beyond it."
                                   -- Ayn Rand, _Atlas Shrugged_



- -------------------------

From: [e-mail] (robert dixon)
Subject:  Mac Pascal vs. C
Date: 5 Feb 92 15:28:44 GMT
Organization: Naval Postgraduate School, Monterey CA

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>If you like nice environments to program under try Emacs and C on a
>Unix system.  Now, there's an unbeatable combination.
>

 I never thought I'd see emacs mentioned in a Mac newsgroup. I use
emacs about every day, but if I take more than about two weeks off, I
forget about half the keystrokes (let's see . . . esc-w copies, or
does it cut, or is it ctrl-w . . .)

- -------------------------------------------------------------------
Bob Dixon                          "My opinions may not necessarily
Low-Life Grad Student,              be my own . . ."
Naval Postgraduate School,
Monterey, CA                        [e-mail]
- ---------------------------------------------------------------------



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Mac Pascal vs. C
Date: 6 Feb 92 17:44:29 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Douglas Hill) writes:
> Here's one:  Has anyone heard about MacApp's support for AppleEvents?
> Specifically I heard recently that MacApp won't be supporting the
> Object Support Library.  Why?  I wonder if something else better is in
> the works?

MacApp 3.0 supports core AppleEvents (you can't avoid using them) and
normal AEs using the TCommand structure. It will support the Object Model
library in a future incarnation.

Kent Sandvik



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 7 Feb 92 11:05:47 +1300
Organization: University of Waikato, Hamilton, New Zealand

Hmm, the first point I made in my original follow-up seems to have got
lost in all the noise, so I guess I should make it again. :-)

#1 primary absolutely the best advantage of Modula-2 over both Pascal and C:
True separate compilation with scope control, and information hiding.

This means that you can split your code into separate modules, and
control precisely what parts of each module are visible to other modules.
And you can do this without sacrificing type-safeness.
            ---------------------------------

Compare C, which only has 1950's FORTRAN-style "independent" compilation--you
can declare things "extern", but there's no check that your external
declaration matches the way the entity is actually implemented. And to avoid
repeating extern declarations everywhere, you've got this "#include" kludge,
with other kludges stacked upon it to get around a) multiple inclusions and
b) the slowness of recompiling all that source over and over.

Pascal--or at least its UCSD derivatives--has "Units", which don't suffer
from C's drawbacks, but don't give you the control over potential name-space
clashes that you get with Modula-2. Also, Modula-2's compilation units are
split into separate "definition" and "implementation" parts; this means that
you can change the way some service is implemented, and provided the user-
visible semantics (and call interface) hasn't changed, you only need to relink,
not recompile, the client program. And the compiler still enforces its
checks that the definition and implementation parts are consistent.

You can do information hiding without splitting your program into multiple
files, too, by having modules within modules.

And remember, all this is done with absolutely *zero* run-time overhead--
no method tables or run-time representation of object types. It's a set of high-
level abstractions which map straight onto a von-Neumann machine.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
This line intentionally left unfunny.



- -------------------------

From: [e-mail] (Quinn "The Eskimo!")
Subject:  Mac Pascal vs. C
Organization: The University of Western Australia
Date: Wed, 5 Feb 1992 00:59:59 GMT

In article <[e-mail]>, [e-mail] (Jonathan Greenfield) writes:
>
> In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> >
> >* Case-sensitive (I hate this)
>
> Don't most implementations have the ability to turn off case-sensitivity?

Tell that to the people at Metrowerks.  I mailed them specifically (they
replied which was nice) to ask "Is there any change of having a switch
to turn off case sensitivity /especially on keywords/?" and they mailed
back saying there was:
  a) no switch and no plan to put one in
  b) an MPW tool to uppercase keywords in Modula 2 source
A tool is not an ideal solution because it's too damned slow.

Quinn "The Eskimo!"   ([e-mail])   "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
-- One of the world's many case frustrated Modula 2 programmers!




- -------------------------

From: [e-mail]
Subject:  Mac Pascal vs. C
Date: 7 Feb 92 00:27:47 CST
Organization: University of Kansas Academic Computing Services


I've been attempting C for a month now (Pascal was all I did for many years).
And one bit of code has annoyed me.  See what you think.

aShort = 5;
anotherShort = 2;
aDoubleVar = aShort / anotherShort;

I'm sure the C programmers see my annoyance right off.  I want to get 2.5, not
2.  Since the operation (/) is being assigned to a double (or float I suppose
too), why not retain the fractional portion and do fractional division?  So I
do:

aDoubleVar = aShort;
aDoubleVar /= anotherShort;

Seems like a sloppy hack.  Is there a way to tell C how to do its divides?  In
Pascal / and div were very clear and very distinct.

john calhoun-




- -------------------------

From: [e-mail] (John Purlia)
Subject:  Mac Pascal vs. C
Date: 7 Feb 92 20:35:54 GMT
Organization: Qualcomm, Inc., San Diego, CA

In article <[e-mail]>
[e-mail] writes:
> And one bit of code has annoyed me.  See what you think.
>
> aShort = 5;
> anotherShort = 2;
> aDoubleVar = aShort / anotherShort;
>
> 2.  Since the operation (/) is being assigned to a double (or float I
suppose
> too), why not retain the fractional portion and do fractional division?
So I
> do:
>
> aDoubleVar = aShort;
> aDoubleVar /= anotherShort;
>
> Seems like a sloppy hack.  Is there a way to tell C how to do its
divides?

Sure, just cast the operands like so:

aShort = 5;
anotherShort = 2;
aDoubleVar = (double) aShort / (double)anotherShort;

And that should do the trick for youI works for floats too!

...........................................................................
John Purlia          : My brain; not my company's brain.  My brain says...
[e-mail] :      "Just about any movie could be made better
AOL:  <Jpurlia>      :       if one of the characters were a vampire."
...........................................................................



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  Mac Pascal vs. C
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: 8 Feb 92 01:08:17

In article <[e-mail]> [e-mail] writes:
>I've been attempting C for a month now (Pascal was all I did for many years).
>And one bit of code has annoyed me.  See what you think.
>
>aShort = 5;
>anotherShort = 2;
>aDoubleVar = aShort / anotherShort;
>
>I'm sure the C programmers see my annoyance right off.  I want to get 2.5, not
>2.  Since the operation (/) is being assigned to a double (or float I suppose
>too), why not retain the fractional portion and do fractional division?

Along this path lies madness. The current rules for expressions allow to parse
expressions completely bottom-up. If C would have to recognize that the result
will be assigned to a double, it would have to do much more complex parsing.

>So I do:
>
>aDoubleVar = aShort;
>aDoubleVar /= anotherShort;
>
>Seems like a sloppy hack.  Is there a way to tell C how to do its divides?

aDoubleVar = (double) aShort / (double) anotherShort;

>In Pascal / and div were very clear and very distinct.

In C, the casts are very clear and distinct. The thing that I blame C for, in
your example, is to fail silently. IMHO, C should have been designed to not
allow automatical promotion from integer to floating point.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_



- -------------------------

From: [e-mail] (Levent Mollamustafaoglu)
Subject:  Mac Pascal vs. C
Date: 8 Feb 92 23:41:44 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] writes:
>
>I've been attempting C for a month now (Pascal was all I did for many years).
>And one bit of code has annoyed me.  See what you think.
[description of problem about casting deleted]

Of course the best way is to use C++, and get automatic casting wrt
the constituents' types. :-)


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Mac Pascal vs. C
Date: 7 Feb 92 20:11:27 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (John Stracke) writes:
> In article <[e-mail]> [e-mail] (Louis Wu) writes:
> Quite true.  I've noticed that I've become much more hackerly since
> abandoning Pascal.

> >Pascal is for beginners, C is for real programmers, and assembly is for
> >masochists. Surely nothing could be more clear.

> And where do things like Lisp fit in your scheme?

Language wars are weird. It also seems that each new programmer generation
has their own favourite languages, as well as prejudices about other
languages.

I usually take a pragmatic view to a particular use of a language, if
the language helps me with software engineering then it's the right tool,
despite the origin or my background with the language.

Back to the Macintosh programming front, there are languages that are
suitable for Macintosh programming, and there are languages which might
become very useful in future. I don't see a difference between Pascal
and C use, and it really depends on the background whatever language
the developer might prefer.

Alas, the only problem is the hype-hysteria in the computer industry
today, managers are making decisions about language use by attending
conferences and market pressure, instead of using common sense and
engineering criterias.

Anyway, that about language wars.

Kent Sandvik
..who really prefers Scheme, but I guess it will take some time before
this is a viable language solution in the commercial sector...



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 9 Feb 92 04:45:03 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> Hmm, the first point I made in my original follow-up seems to have got
> lost in all the noise, so I guess I should make it again. :-)
>
> #1 primary absolutely the best advantage of Modula-2 over both Pascal and C:
> True separate compilation with scope control, and information hiding.

> This means that you can split your code into separate modules, and
> control precisely what parts of each module are visible to other modules.
> And you can do this without sacrificing type-safeness.

ahum, Common Lisp has packages, which is really a data structure that establishes
a mapping from print names to symbols. At any given time one package is current,
which the Lisp system is using in when it translates strings into symbols.

Even better, CL has modules, which is a subsystem which is loaded from one
or *more* files. A module may or may not consist of one or several packages.

I think we agree that name space handling is very poor with C and C++, even
if data abstraction in forms of class scoping helps a little bit with C++.
But there's always the problem with class naming schemes, and I've even
seen serious suggestions that each future C++ class library vendor will
place a pre-index in front of the class name, as in TAppleString :-).

Kent Sandvik



- -------------------------

From: [e-mail] (John Nagle)
Subject:  Mac Pascal vs. C
Date: 9 Feb 92 17:46:54 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Levent Mollamustafaoglu) writes:
>Of course the best way is to use C++, and get automatic casting wrt
>the constituents' types. :-)

      C++ has its own set of problems, of course.  Also, MPW C++ is two
generations behind the language spec, which calls for templates and exceptions.
Zortech C++ is defective (and maybe defunct; the expected Fall 91 release
still hasn't happened).  Think C is nonstandard.  So even if you like
C++, the tools are in bad shape.

      Yet there are few alternatives.  Plain C is obsolete given the direction
MacApp is going.  Pascal also seems to be a dead end.  Modula seems to
have peaked.  Eiffel is an academic toy.  Lisp and its dialects died with
AI.  Hypertalk is too slow.  Smalltalk is also too slow.  Basic is too tacky.
Ada is too expensive.

       The Xanadu crowd are writing in Smalltalk and machine-translating
to C++, with good results, but this technology isn't ready for prime time.

                    John Nagle



- -------------------------

From: [e-mail] (Robert H Earhart)
Subject:  Mac Pascal vs. C
Date: 9 Feb 92 20:26:33 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA


  Lisp? Dead? I beg your pardon... Macintosh Common Lisp is a wonderful
environment... and also required for a couple of computer science
classes here at CMU. :)

  -Rob

  (I still prefer Pascal. :)



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Modula-2
Date: 9 Feb 92 22:07:54 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:

[in response to my description of name-space control in Modula-2]
> ahum, Common Lisp has packages, which is really a data structure that establishes
> a mapping from print names to symbols. At any given time one package is current,
> which the Lisp system is using in when it translates strings into symbols.
>
> Even better, CL has modules, which is a subsystem which is loaded from one
> or *more* files. A module may or may not consist of one or several packages.
>
> I think we agree that name space handling is very poor with C and C++, even
> if data abstraction in forms of class scoping helps a little bit with C++.

Wonderful, Kent, but you forgot the latter part of my posting, where I
pointed out that Modula-2 achieves what it does with no special run-time
requirements. Let's see, so far I've successfully written dozens of HyperCard
externals, a couple of FKEYs, an After Dark display, and a dcmd for MacsBug,
all using Modula-2. Try doing that with Common Lisp sometime :-).

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Modula-2
Date: 10 Feb 92 19:54:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
> In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> [in response to my description of name-space control in Modula-2]
> > ahum, Common Lisp has packages, which is really a data structure that establishes
> > a mapping from print names to symbols. At any given time one package is current,
> > which the Lisp system is using in when it translates strings into symbols.
> >
> > Even better, CL has modules, which is a subsystem which is loaded from one
> > or *more* files. A module may or may not consist of one or several packages.
> >
> > I think we agree that name space handling is very poor with C and C++, even
> > if data abstraction in forms of class scoping helps a little bit with C++.
>
> Wonderful, Kent, but you forgot the latter part of my posting, where I
> pointed out that Modula-2 achieves what it does with no special run-time
> requirements. Let's see, so far I've successfully written dozens of HyperCard
> externals, a couple of FKEYs, an After Dark display, and a dcmd for MacsBug,
> all using Modula-2. Try doing that with Common Lisp sometime :-).

..some day we will have hardware that will handle dynamic/reflective languages
performance wise well, some day... Anyway, I tried to point out the nice
things with Common Lisp module/package handling. Anyway, imagine writing
a dcmd in Lisp :-). Actually the whole debugging environment is maybe part of the
whole runtime, so you will write a generic function which will trigger the 'dcmd'
style function.

Kent



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Mac Pascal vs. C
Date: 10 Feb 92 19:59:38 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (John Nagle) writes:
>       C++ has its own set of problems, of course.  Also, MPW C++ is two
> generations behind the language spec, which calls for templates and exceptions.
> Zortech C++ is defective (and maybe defunct; the expected Fall 91 release
> still hasn't happened).  Think C is nonstandard.  So even if you like
> C++, the tools are in bad shape.

Most C++ compiler vendors don't have exception handling, including good old
Cfront 3.0 from AT&T. Ditto with templates, few compilers have this feature
today. It seems that people take ARM for granted, and assume that everything
described in ARM should work on every C++ compiler. Even Cfront doesn't
handle every ARM feature.

> Yet there are few alternatives.  Plain C is obsolete given the direction
> MacApp is going.  Pascal also seems to be a dead end.  Modula seems to
> have peaked.  Eiffel is an academic toy.  Lisp and its dialects died with
> AI.  Hypertalk is too slow.  Smalltalk is also too slow.  Basic is too tacky.
> Ada is too expensive.

I wonder what languages our successful Macintosh developers are using... :-).
Alas, C/C++ will be the grunt-language for personal computer software development
for the next 4-8 years.

Kent Sandvik/DTS



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Modula-2
Date: 11 Feb 92 17:08:41 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:

> ..some day we will have hardware that will handle dynamic/reflective languages
> performance wise well, some day...

Sorry, Kent, but it's been tried, over and over. Remember the Burroughs
ALGOL machines, the Symbolics LISP machine, even the Intel 432 ... pushing
that sort of complexity into the hardware doesn't make it any more efficient.
And we haven't been making all these advances in RISC design only to throw it
all away at the software level.

No, I predict that, as programmers notice that some of these complex new tools
are actually slowing down their development efforts, there will be a
resurgence of the "Keep It Simple, Stupid!" school of programming language
design. And I think that Niklaus Wirth will be alive to see it.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.



- -------------------------

Subject:  Modula-2 (was Re: Mac Pascal vs. C)
From: [e-mail] (Bruce Hoult)
Date: Tue, 11 Feb 1992 09:22:48 GMT
Organization: Actrix Information Exchange, Wellington, New Zealand

[e-mail] (Lawrence D'Oliveiro) writes:

>You can do information hiding without splitting your program into multiple
>files, too, by having modules within modules.

Ditto for nested classes in C++.

>And remember, all this is done with absolutely *zero* run-time overhead--
>no method tables or run-time representation of object types. It's a set of
>high-level abstractions which map straight onto a von-Neumann machine.

Ditto for C++.  That "no method tables or run-time representation of
object types" bit is a red herring, since that is only present when you're
doing things that Modula-2 can't do at all (except by manually building
method tables using function pointers).
--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Modula-2
Organization: Kalamazoo College
Date: Tue, 11 Feb 1992 15:25:31 GMT

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
>And we haven't been making all these advances in RISC design only to throw it
>all away at the software level.

Here's a good place to point out that, in five years, the newest
computers will be running Macintosh code with software emulation of the
680x0 chip.  The Toolbox, however, will be written in the processor's
native assembly language.

This means that all the "clever" techniques that bypass the toolbox with
carefully-unrolled cycle-pinching loops will be an order of magnitude
slower than the "stupid" programs that call the Toolbox.

Poetic justice or monstrous tragedy?  You decide.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 11 Feb 92 21:56:55 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail]
(Bruce Hoult) writes:
> [e-mail] (Lawrence D'Oliveiro) writes:
>
>>You can do information hiding without splitting your program into multiple
>>files, too, by having modules within modules.
>
> Ditto for nested classes in C++.
>
>>And remember, all this is done with absolutely *zero* run-time overhead--
>>no method tables or run-time representation of object types. It's a set of
>>high-level abstractions which map straight onto a von-Neumann machine.
>
> Ditto for C++.  That "no method tables or run-time representation of
> object types" bit is a red herring, since that is only present when you're
> doing things that Modula-2 can't do at all (except by manually building
> method tables using function pointers).

In article <[e-mail]>, I said:

> #1 primary absolutely the best advantage of Modula-2 over both Pascal and C:
> True separate compilation with scope control, and information hiding.

So tell us: how good are the separate compilation facilities in C++?

I'll go home and get my "red herring" example as well, and see how well
you can handle that in C++...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00



- -------------------------

From: [e-mail] (Patrick Logan)
Subject:  Modula-2
Organization: Mentor Graphics Corporation
Date: Tue, 11 Feb 1992 20:27:25 GMT

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
   In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
   > ..some day we will have hardware that will handle dynamic/reflective languages
   > performance wise well, some day...

   Sorry, Kent, but it's been tried, over and over. Remember the Burroughs
   ALGOL machines, the Symbolics LISP machine, even the Intel 432 ... pushing
   that sort of complexity into the hardware doesn't make it any more efficient.
   And we haven't been making all these advances in RISC design only to throw it
   all away at the software level.

Special purpose hardware is not needed. It has already been
demonstrated that a little cleverness in the compiler and run-time
system goes a long way. The hardware is nice, but not necessary.

   No, I predict that, as programmers notice that some of these complex new tools
   are actually slowing down their development efforts, there will be a
   resurgence of the "Keep It Simple, Stupid!" school of programming language
   design. And I think that Niklaus Wirth will be alive to see it.

The trend appears to be heading toward C++. The trend within the C++
world is towards the kinds of tools traditionally associated with LISP
and Smalltalk: browsers, graphers, interpreters, debuggers, even
automatic memory management. These things generally help and faster,
general-purpose hardware is only going to make them perform better,
continuing C++'s popularity.

In the long run, other languages and styles will survive. C++ will
eventually evolve or be replaced with something more effective. Let's
hope we'll all be alive to see it.
--
Patrick Logan, [e-mail],
Voice: [phone] x2907, FAX: [phone]
Mentor Graphics Corp., Bldg. C, 8005 SW Boeckman Rd., Wilsonville, OR 97070
I can't gete the .signature virus and I can't gete the .signature



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 12 Feb 92 20:53:08 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail]
(Bruce Hoult) wrote:
> That "no method tables or run-time representation of object types" bit
> is a red herring...

In article <[e-mail]>, I said:
> I'll go home and get my "red herring" example as well...

On second thoughts, I won't. I was rather hoping to conduct this discussion
on a courteous, civilized level. And I still would like to. But I'm not
prepared to put up with comments like that.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00



- -------------------------

From: [e-mail] (Ian Joyner)
Subject:  Mac Pascal vs. C
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 12 Feb 1992 00:58:08 GMT

someone writes:
>> Yet there are few alternatives.  Plain C is obsolete given the direction
>> MacApp is going.  Pascal also seems to be a dead end.  Modula seems to
>> have peaked.  Eiffel is an academic toy.  Lisp and its dialects died with
>> AI.  Hypertalk is too slow.  Smalltalk is also too slow.  Basic is too tacky.
>> Ada is too expensive.

Whoever you are, I suggest you get your facts straight before making such
silly prejudicial remarks. Often you will find that the world is
different to the way you condemn it to be in your own head.
--
Ian Joyner                                     ACSNet: [e-mail]
ACUS (Australian Centre for Unisys Software)   Internet: [e-mail]
Tel [phone]      Fax [phone]       UUCP: ...uunet!munnari!syacus.oz



- -------------------------

From: [e-mail] (Brett Kottmann)
Subject: C and function overloading (was Re: Mac Pascal vs. C)
Date: 12 Feb 92 13:27:37 EST
Organization: Logicon Technical Services, Inc.

In article <[e-mail]>, [e-mail] (Matthias Ulrich Neeracher) writes:
> In article <[e-mail]> [e-mail] writes:
>>I've been attempting C for a month now (Pascal was all I did for many years).
>>And one bit of code has annoyed me.  See what you think.
>>
>>aShort = 5;
>>anotherShort = 2;
>>aDoubleVar = aShort / anotherShort;
>>
>>I'm sure the C programmers see my annoyance right off.  I want to get 2.5, not

    Well, how about misunderstaning of what C is and does...?

>...
> In C, the casts are very clear and distinct. The thing that I blame C for, in
> your example, is to fail silently. IMHO, C should have been designed to not
> allow automatical promotion from integer to floating point.
>

    What C does is use / to mean differnent things with different
operators.  It mean integer division when using integers, complex division when
using reals.

    Once you've written a program in C using real numbers, you remember
this for life... :)

    It really is a feature, and not something to raise informational
messages.  You have to assume a competent programmer.  Although there could
always be a -novice switch for the compiler. :)

Brett
=============================OFFICIAL=DISCLAIMER================================
The opinions and views expressed here are strictly my own and do not
necessarily reflect the official position of either the U.S. Air Force
or its contractors.
=====================DO=NOT=REMOVE=TAG=UNDER=PENALTY=OF=LAW===:)================



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Modula-2
Date: 13 Feb 92 05:01:26 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail]
(Jamie R. McCarthy) writes:
> Here's a good place to point out that, in five years, the newest
> computers will be running Macintosh code with software emulation of the
> 680x0 chip.  The Toolbox, however, will be written in the processor's
> native assembly language.
>
> This means that all the "clever" techniques that bypass the toolbox with
> carefully-unrolled cycle-pinching loops will be an order of magnitude
> slower than the "stupid" programs that call the Toolbox.
>
> Poetic justice or monstrous tragedy?  You decide.

How about "business opportunity"? :-)

Five years is a long time; long enough to make a tidy fortune selling
a neato program that runs fast on today's machines at least partly because
of cycle-pinching toolbox-bypassing techniques. Then when the new machines
come out, you'll have enough of a financial base to develop the new, even
faster version, and charge everybody a nice fee to upgrade.

Lawrence "I work at a university; what do *I* know about
business opportunities?" D'Oliveiro



- -------------------------

From: [e-mail] (Bruce Hoult)
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 13 Feb 92 02:03:35 GMT
Organization: Actrix Information Exchange, Wellington, New Zealand

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, I said:
>
> #1 primary absolutely the best advantage of Modula-2 over both Pascal and C:
> True separate compilation with scope control, and information hiding.
>
>So tell us: how good are the separate compilation facilities in C++?

In theory, lousy.  In practice, workable (just) but lousy.

Modula-2 and Ada certainly have better control over the scope of names
with the "IMPORT foo" and "FROM foo IMPORT bar" idea, but the ANSI C++
committee are studying several proposals to do the same type of thing
with classes in C++.

Here's a message from BIX from earlier today -- personally I think the
suggested syntax is an ugly as hell, but it does illustrate that the
problem is known and is being worked on.

==========
c.plus.plus/x3j16 #173, from bstroustrup, 1112 chars, Wed Feb 12 13:25:25 1992
Comment to 171. Comment(s).
- --------
 > Perhaps.  And we can probably kill .h files and consider some
 > issues for a C++ environment issues at the same time.

I very much doubt it. Anything powerful enough to make .h files redundant would
also be complicated and controversial. We would also have to keep .h files for
compatibility anyway.

My thoughts on name space pollution issues is more along the lines of actually
making .h filesmore useful as interface definitions.

Here is one of several ideas being discussed in the extensions working group:

    :: ATT :: {
        // ...
        void f();
        void g();
    }

This defines a name space ATT. Including this text would let you use the
names from the ATT ``pseudo-global'' scope unqualified:

        f();
        g();

However if you also included another such scope, say

    :: MS :: {
        int f();
        void h();
    }

then
    f();
becomes ambiguous and you'll have to qualify it

    int i = MS::f();
    ATT::f();

names that doesn't clash would not need qualification:

    g();    // meaning ATT::g()
    h();    // meaning MS::h().

Please note that this all have to be looked into in great detail before
it is ready for anything but debate.

- ---------

>I'll go home and get my "red herring" example as well, and see how well
>you can handle that in C++...

I look forward to the challenge..  :-)


--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail]
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 14 Feb 92 03:02:19 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> In article <[e-mail]>, [e-mail]
> (Bruce Hoult) wrote:
> > That "no method tables or run-time representation of object types" bit
> > is a red herring...
>
> In article <[e-mail]>, I said:
> > I'll go home and get my "red herring" example as well...
>
> On second thoughts, I won't. I was rather hoping to conduct this discussion
> on a courteous, civilized level. And I still would like to. But I'm not
> prepared to put up with comments like that.

Huh?  What did I say?  I'm sorry if I've somehow unwittingly offended you,
but all I was saying is that there isn't anything in Modula-2 that requires
method tables or run-time representation of object types when implemented
in C++.  There are things that are *better* implemented that way, but you
always have the option of using exactly the same tools as you would in M2.

--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Modula-2
Date: 14 Feb 92 05:53:19 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> > ..some day we will have hardware that will handle dynamic/reflective languages
> > performance wise well, some day...

> Sorry, Kent, but it's been tried, over and over. Remember the Burroughs
> ALGOL machines, the Symbolics LISP machine, even the Intel 432 ... pushing
> that sort of complexity into the hardware doesn't make it any more efficient.
> And we haven't been making all these advances in RISC design only to throw it
> all away at the software level.

Don't mention the Bu** word for me (former Sperry person who left the company
after the invasion :-) ).

I'm not talking about the issue of big mainframe or specialized high end
workstations tuned for *one* particular language (ALGOL and B-/A-series from B***,
Symbolics and TI Explorers for LISP). I'm personally looking at all these
new cute consumer electronics boxes from Japan that have their own small
cute OS systems which handle their memory management quite well. Ever heard
about a Sharp time management assistant that gets a bomb box? In these
cases memory management handling is of utmost importance, we can't expect
a Sharp use increase the heap space...

> No, I predict that, as programmers notice that some of these complex new tools
> are actually slowing down their development efforts, there will be a
> resurgence of the "Keep It Simple, Stupid!" school of programming language
> design. And I think that Niklaus Wirth will be alive to see it.

Yes, I also subscribe to the notion of "Reduced Feature Programming Languages",
Scheme is one example of such language design. C *was* such a language. But as
with the case of RISC, where compilers produce optimal code for reduced instruction
sets, we need hardware that handles memory management in collaboration with the
language. This is the reason I do believe that the merge of consumer electronics
and computers will produce new languages and operating systems which work together
with hardware, and where for instance the handling of memory is far more transparent
than it is today in the world of mallocs and NewHandles.

Kent Sandvik
- -
Not speaking for any special company



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Modula-2 (was Re: Mac Pascal vs. C)
Date: 13 Feb 92 20:38:06 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Bruce Hoult) writes:
>
> [e-mail] (Lawrence D'Oliveiro) writes:
>
> >You can do information hiding without splitting your program into multiple
> >files, too, by having modules within modules.
>
> Ditto for nested classes in C++.
>
> >And remember, all this is done with absolutely *zero* run-time overhead--
> >no method tables or run-time representation of object types. It's a set of
> >high-level abstractions which map straight onto a von-Neumann machine.
>
> Ditto for C++.  That "no method tables or run-time representation of
> object types" bit is a red herring, since that is only present when you're
> doing things that Modula-2 can't do at all (except by manually building
> method tables using function pointers).

Modula-2/C++/Lisp bashing on comp.sys.mac.programmer :-). Anyway, I've used
C++ for a long time, and it always beats me why we are stuck to a file-level
type coercion of type information and labels. Certainly module use is a better
way to restrict, load and control class definitions. Nested classes in C++
is just an attempt to push the problem down to class level, and doesn't solve
the problem with class naming clashes.

With the future development environments based on a database (type the Lucid
C++ dev. environment) the use of name scoping is resolved by the underlying
object/source code database. So in that sense the problem might suddenly go away.

Kent Sandvik/DTS



---------------------------

End of C.S.M.P. Digest
**********************